🤖 Codex Code Review

No findings.

crates/vm/levm/src/opcode_handlers/keccak.rs:17-62 looks sound: the new fast path only changes the len == 0 case, still charges gas before branching, and calculate_memory_size(offset, 0) already resolves to 0 in crates/vm/levm/src/memory.rs:371-379, so this does not appear to alter EVM memory-expansion semantics. The constant’s limb ordering is also covered by the added unit test.

Residual risk: I could not run the Rust test locally in this environment because cargo/rustup attempted to write under a read-only /home/runner/.rustup, so this review is based on static analysis only.

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

Greptile Summary

This PR short-circuits the KECCAK256 opcode handler in the LEVM when input length is zero, returning the precomputed keccak256("") constant (EMPTY_KECCAK_U256) instead of running the full permutation. Gas accounting is unchanged; both calculate_memory_size and load_range already early-return for size == 0, so memory semantics are fully preserved.

• Introduces a compile-time EMPTY_KECCAK_U256 constant with correct little-endian limb ordering, verified against NativeCrypto.keccak256(&[]) in a new unit test.
• The optimization targets a well-documented ~19x throughput gap on zero-length inputs compared to reth, with no behavioral change for non-empty inputs.

Confidence Score: 5/5

Safe to merge — the change is narrowly scoped, the constant is mathematically verified by the accompanying test, and gas/memory accounting paths are untouched.

The short-circuit only fires when len == 0, a path that was already a no-op in calculate_memory_size and load_range. The constant's limb ordering matches the u256_from_big_endian encoding used everywhere else in the codebase, and the unit test provides a runtime proof against the live hasher. No edge cases were left uncovered.

No files require special attention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[KECCAK256 opcode] --> B[Pop offset, len from stack]
    B --> C[Compute & charge gas\ncalculate_memory_size + keccak256 word cost]
    C --> D{len == 0?}
    D -- Yes --> E[Return EMPTY_KECCAK_U256\nprecomputed constant\nskip memory load & permutation]
    D -- No --> F[memory.load_range offset, len]
    F --> G[crypto.keccak256 bytes]
    G --> H[u256_from_big_endian hash]
    E --> I[stack.push hash]
    H --> I
    I --> J[OpcodeResult::Continue]

_{Reviews (1): Last reviewed commit: "perf(l1): short-circuit KECCAK256 on emp..." | Re-trigger Greptile}

🤖 Kimi Code Review

The optimization to skip the keccak permutation for empty input is a standard performance improvement used by other clients (geth, revm, etc.). However, there's a potential consensus-critical issue regarding memory expansion.

Critical Check Required

crates/vm/levm/src/opcode_handlers/keccak.rs, lines 40-48:
The optimization skips memory.load_range(offset, len) when len == 0. If load_range has side effects (e.g., expanding the memory vector to accommodate offset + len bytes or validating memory access bounds), skipping it violates EVM semantics. Even with zero length, the EVM must ensure memory is expanded to at least offset bytes and charge appropriate gas.

Verify that:

1. Memory expansion and gas charging for offset + len occur during the word_size calculation (line 31) or earlier in the gas pricing phase
2. load_range is side-effect free and purely reads data

If memory expansion happens during load_range, you must either:

• Keep the load_range(offset, 0) call to trigger expansion, or
• Ensure memory expansion is handled independently before this handler executes

Code Correctness

Lines 17-21: The constant values correctly represent the little-endian U256 encoding of keccak256(""):

• c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470
• Array order [least_sig_u64, ..., most_sig_u64] is correct for ethrex_common::U256

Style

Line 13: The import use ethrex_common::U256; should be grouped with the existing ethrex_common import (line 14) per Rust conventions:

use ethrex_common::{U256, utils::u256_from_big_endian};

Testing

Lines 56-60: The unit test correctly verifies the constant against the cryptographic implementation. Consider also adding an integration test ensuring KECCAK256 with size=0 charges the correct gas and handles memory expansion at the boundary, though this may be covered by existing opcode test suites.

Recommendation: Confirm the memory expansion behavior of load_range before merging. If expansion is handled elsewhere, this optimization is correct and safe.

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

🤖 Claude Code Review

Here is the review for PR #6775 — perf(l1): short-circuit KECCAK256 on empty input.

PR Overview

Short-circuits the KECCAK256 opcode handler when len == 0 by returning a precomputed constant (keccak256("")) instead of running the Keccak permutation. Gas accounting is unchanged. The PR includes a unit test verifying the constant.

Correctness

Constant value — verified correct. keccak256("") = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. The U256([u64; 4]) constructor stores words in little-endian order (index 0 = least significant), and the encoding in the PR matches exactly:

[0] 0x7bfad8045d85a470  ← LSW
[1] 0xe500b653ca82273b
[2] 0x927e7db2dcc703c0
[3] 0xc5d2460186f7233c  ← MSW

The unit test confirms the constant against the live hasher, which is the right approach.

Memory expansion — no behavioral change. For len == 0:

• calculate_memory_size(offset, 0) returns Ok(0) early (memory.rs:372–373)
• memory::load_range(offset, 0) returns Bytes::new() early (memory.rs:128–129)

Both paths were already no-ops before the branch was introduced. The branch does not alter observable memory state.

Gas accounting — unchanged and correct. gas_cost::keccak256 is called before the if len == 0 branch (line 34–38), so it always fires. With new_memory_size=0 and size=0, only the static 21-gas base is charged, which matches the EVM spec.

EVM spec compliance — KECCAK256 of zero-length input must return the well-known constant. This is correct.

Minor Issues

Import style (line 14–15) — the two imports from ethrex_common should be merged per Rust convention:

// before
use ethrex_common::U256;
use ethrex_common::utils::u256_from_big_endian;

// after
use ethrex_common::{U256, utils::u256_from_big_endian};

Comment wording (line 17–18) — "hot path skips the permutation" is misleading. Empty-input keccak is an optimised cold path, not the hot path. Consider: "Skips the permutation for zero-length input; the result is a well-known constant."

Test hardening (optional) — the current test catches a wrong constant or a wrong hasher, but not a mutual bug where both return the same wrong value. Adding a literal byte assertion is a low-cost guard:

assert_eq!(
    NativeCrypto.keccak256(&[]),
    hex_literal::hex!("c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470")
);

This is advisory — the existing test is already meaningful.

Summary

The optimization is correct, spec-compliant, and well-tested. Gas and memory semantics are preserved. The only actionable change is merging the two use ethrex_common:: lines. Everything else is advisory.

Automated review by Claude (Anthropic) · sonnet · custom prompt

Lines of code report

Total lines added: 28
Total lines removed: 0
Total lines changed: 28

+-----------------------------------------------------+-------+------+
| File                                                | Lines | Diff |
+-----------------------------------------------------+-------+------+
| ethrex/crates/vm/levm/src/opcode_handlers/keccak.rs | 57    | +28  |
+-----------------------------------------------------+-------+------+

Benchmark Results Comparison

No significant difference was registered for any benchmark run.

Benchmark Block Execution Results Comparison Against Main